[00:00.000 --> 00:05.140]  Hi everyone, my name is Chloe Mostagi and I'm happy to be on the disclosure panel with you
[00:05.140 --> 00:11.740]  for this wonderful biohacking village. And so before I get started, I just wanted to let you
[00:11.740 --> 00:16.320]  know who I am so you have a better idea of basically what the content I'm going to share
[00:16.320 --> 00:21.480]  with you. So I am the VP of Strategy over at Point3Security and when I'm not that, I'm an
[00:21.480 --> 00:26.980]  ethical hacker advocate. And if you're wondering what is an ethical hacker advocate, basically I'm
[00:26.980 --> 00:32.760]  trying to fight for rights for hackers and also to change the imagery and the wording that the
[00:32.760 --> 00:37.300]  press tends to use about us in a very negative light. But when I'm not doing that, I also am
[00:37.300 --> 00:42.020]  trying to push for diverse inclusion within the community. I am the president and co-founder of
[00:42.020 --> 00:47.140]  WOSEC and when I'm not that, I'm also the founder of WeAreHackers, which used to be formally called
[00:47.140 --> 00:54.960]  as LoneHackers, but WeAreHackers is a private online community of hackers who are underrepresented
[00:54.960 --> 01:01.000]  genders. And yes, we hack at all different levels and have workshops and all that fun stuff. And
[01:01.000 --> 01:08.140]  yes, I am a parent. If you're wondering what's a parent, it's basically a parent of any dogs, cats,
[01:08.140 --> 01:12.460]  and hamsters, I guess, and bunnies or any of those kind of things. Anyway,
[01:12.460 --> 01:17.980]  Shirlika and Luna, which are both some sheebs. And also I am the Hacker Book Club organizer and
[01:17.980 --> 01:24.660]  what we do is one of those things where we read a new book every month written by someone in the
[01:24.660 --> 01:29.780]  about the hacker community and the author and the people that are mentioned in the book do attend
[01:29.780 --> 01:36.800]  our weekly meetups on Tuesday at 5 p.m pacific time. Anyway, enough about me. If you want to
[01:36.800 --> 01:40.600]  follow me, feel free to. I'm on Twitter and Instagram. Let's go into the good stuff though.
[01:41.460 --> 01:47.180]  So what usually when we see the word hacker or when we type in hacker in Google or whatnot,
[01:47.180 --> 01:53.060]  we get like this these type of images, this dark hooded figure, but also we see these ones that
[01:53.060 --> 01:59.700]  have whole cutout and you know. Anyway, let's just be honest with each other. This is really
[01:59.700 --> 02:05.700]  annoying at this point because what's happening is that people are seeing us in this way.
[02:05.740 --> 02:10.900]  Something that looks like a criminal. And it's not just that, but even if you type in
[02:10.900 --> 02:16.940]  ethical hacker or criminal hacker, if you see on both sides of this, you get the exact same
[02:16.940 --> 02:23.560]  imagery. So which is even more annoying because it looks like we're still having this situation
[02:23.560 --> 02:30.160]  ongoing. And it's not the imagery either. It's also the words being used. The media, which is
[02:30.160 --> 02:37.020]  press and marketing organizations, keep using the term hacker in a negative way when they should
[02:37.020 --> 02:44.320]  be saying malicious actors or cyber criminals. But if you're wondering how does this imagery
[02:44.320 --> 02:51.120]  impact us, I'm glad that you're asking because I'm one of those people that's obsessed with brains.
[02:51.300 --> 02:55.160]  So we're going to talk about them. All right, so first things first that you should know about
[02:55.160 --> 03:00.420]  when it comes to your brain is we're going to have to dive into the amygdala, which is an almond
[03:00.420 --> 03:07.240]  shaped part of your brain within the temporal lobe. Now the thing to know about the amygdala,
[03:07.240 --> 03:11.900]  it sorts who's like us, who's not like us. And because of that, it's the fear versus flight
[03:11.900 --> 03:17.340]  mechanism. So if the person somehow has a connection like us or looks like us, we're like,
[03:17.340 --> 03:23.020]  this is a friend versus if the person doesn't look like us or we have no association, never
[03:23.020 --> 03:29.360]  had any conversation with someone that is that type of person, we see them as an enemy. And
[03:29.360 --> 03:35.180]  because of that, that is how we have these things called socially constructed beliefs.
[03:35.180 --> 03:41.380]  One in the media when they share hackers and imagery of this hooded figure or using the term
[03:41.380 --> 03:46.880]  hacker, what is happening is socially constructed beliefs are now being implanted in other people's
[03:46.880 --> 03:54.920]  minds that hackers are criminals and that all of us are criminals, we're bad people. And because
[03:54.920 --> 04:03.320]  of that, it has created this fear in the public. Now to know about is that when the amygdala sees,
[04:03.320 --> 04:09.400]  for example, let's put it this way, you know when we always tell someone that we're a hacker,
[04:10.260 --> 04:15.820]  and usually the person takes a step back and kind of goes, or they're like the mouth drops,
[04:15.820 --> 04:20.520]  or their eyes get a little big. They're nervous, but they don't want to come off that they are,
[04:20.520 --> 04:24.720]  but they totally are. And you know it. And you're like, dang it, I should have gone the security
[04:24.720 --> 04:30.160]  researcher term, but you did it. It's okay. Anyway, what happens is at that point,
[04:30.160 --> 04:35.860]  what's happening is that person knows that now you're a hacker. And they've seen the images,
[04:35.860 --> 04:39.480]  they've heard the words in the press and whatnot of hacker. And when they see you,
[04:39.480 --> 04:42.940]  and you tell them you're a hacker, they're taking the step back because they're trying
[04:42.940 --> 04:50.800]  to figure out something. If you are a friend or a foe. Now the thing to note about the amygdala
[04:50.800 --> 04:55.100]  is that even though it sends that signal, it's completely subconscious. So you don't even know
[04:55.100 --> 04:59.720]  that you have a fear of it. The only time when you know that it's a fear is if it comes in the
[05:00.340 --> 05:05.340]  prefrontal cortex of your brain, which is right here. Anyway, so what it does is that it sends
[05:05.460 --> 05:11.740]  a message that are saying warning, warning, there's a hacker near you. Be careful. It's a
[05:11.740 --> 05:19.720]  criminal. They do bad, terrible things. Now the thing is, is that that person now has a choice
[05:19.720 --> 05:27.460]  to react or to ignore it. Now the only way that you can question socially constructed beliefs and
[05:27.460 --> 05:33.700]  biases is through stories and from meeting people within that community. The thing is,
[05:33.700 --> 05:38.100]  when we're inside our bubble, we're protected from these things. We have our own beliefs and it's
[05:38.100 --> 05:43.140]  constantly being verified that you are correct always. When we go outside our bubble, that's
[05:43.140 --> 05:48.040]  when we realize you're not actually, you don't know everything. And to be comfortable with the
[05:48.040 --> 05:54.760]  uncomfortable is always a hard thing. So what's the main takeaway if you're wondering, Chloe,
[05:54.760 --> 05:58.840]  why are we still talking about the brain and the amygdala? The thing you need to understand is that
[05:59.480 --> 06:05.820]  it's not permanent. These socially constructed ideas are never permanent. You have a choice
[06:06.280 --> 06:11.620]  to learn about another perspective, but they have to hear the other perspective. And right now
[06:11.620 --> 06:17.560]  in the press, we're not seeing that yet. And because of that, we're still being seen as
[06:17.560 --> 06:25.920]  criminals. So, and because of this fear and the public perception, we still have a situation where
[06:25.920 --> 06:31.680]  93% of the Forbes Global 2000 don't have a vulnerability disclosure program. And 60% of
[06:31.680 --> 06:38.940]  hackers do not report vulnerabilities out of fear of being prosecuted. And laws that are preventing
[06:39.600 --> 06:48.820]  like good hacking are such as the CFA and DMCA. And because of this stigma associated with being
[06:49.060 --> 06:54.920]  a hacker and how the public sees us, it also increases the chances of having more malicious
[06:55.560 --> 07:01.120]  attackers, not hackers, attackers. But I try to catch you there in that slide and see if you caught
[07:01.120 --> 07:07.420]  it or not. But overall, what we need to know about is that there are legislation out there that is
[07:07.420 --> 07:13.560]  hurting us still to this day. And what we need right now are some amendments. So, for example,
[07:13.560 --> 07:19.560]  the anti-hacking laws, the Computer Fraud Abuse Act was actually created in 1984 because Ronald
[07:19.560 --> 07:24.460]  Reagan watched this movie called War Games and panicked. As you can tell, many of the rules and
[07:24.460 --> 07:30.380]  laws that have been created are usually stemmed from panic and fear based and not through empathy.
[07:30.380 --> 07:35.020]  They never really had a conversation with the hacker community to say, hey, is this right or
[07:35.020 --> 07:40.800]  wrong what we're doing here? And the thing is, is that we need to push more than ever some amendments
[07:40.800 --> 07:46.800]  for this. Yes, we do believe that, you know, malicious actors should have to deal with prosecution.
[07:47.020 --> 07:52.800]  But if we are going, you know, within scope, then we shouldn't be having to worry about being
[07:52.800 --> 07:58.700]  prosecuted. If we go out of scope by accident, we shouldn't have to worry about being prosecuted.
[07:58.700 --> 08:04.280]  However, if we go out of scope and we exploit, okay, yes, we did something bad with a malicious
[08:04.280 --> 08:11.400]  intent. And anti-circumvention laws are the copyright acts. And basically seeing reverse
[08:11.400 --> 08:18.300]  engineering is seen as a breach. Not a breach, but it's just wrong. It's not legal. So these are
[08:18.300 --> 08:23.380]  things to consider and remember of. And of course, we have an acceptable use policy, which is every
[08:23.380 --> 08:29.100]  time that you are on your iPhone or any of those things, it's like, please check this terms and
[08:29.100 --> 08:33.660]  conditions. I know some of us try to read it, but it's really hard to understand because we're not
[08:33.660 --> 08:41.180]  attorneys. So it makes it even harder for us to understand what we're reading. And also many of us,
[08:41.180 --> 08:46.320]  English is not our first language. And so that's the other issue, is that there's all these things
[08:46.320 --> 08:54.480]  that are set up for hackers ourselves to fall into a situation of being prosecuted. And it's scary.
[08:55.660 --> 09:00.680]  But if you want to start changing things, there's one step that you can do right now, which is if
[09:00.680 --> 09:07.840]  you go to change.org, there's this petition that was created, which basically tries to get all of
[09:07.840 --> 09:13.600]  us to sign it. So then we can bring it and push for changes to happen. We need organizations to
[09:13.600 --> 09:18.440]  start trusting us and have bilateral trust that they will not prosecute us if we report a vulnerability
[09:18.440 --> 09:25.700]  and we don't exploit it. We're also asking for politicians to update. Update the laws that we have.
[09:25.700 --> 09:31.000]  Creating amendments is one of those because it's the laws that they've created are preventing good
[09:31.000 --> 09:36.940]  hacking. And also for the media to let them know that please, if you're reporting about the hacker
[09:36.940 --> 09:42.560]  community, please keep us in a good light. But if it is someone who did something malicious, don't call
[09:42.560 --> 09:48.260]  them a hacker. Call them a malicious actor or cyber criminal. And that's one of those important things.
[09:48.260 --> 09:53.740]  But us as a community, we have to try to do our best to stay within scope and not exploit because
[09:53.740 --> 10:01.060]  when one of us breaks that, it takes us 10 steps backwards. And I'm looking forward to the other
[10:01.060 --> 10:07.720]  panelists sharing more about what on their side and what they're seeing when it comes to disclosure.
[10:08.280 --> 10:12.940]  So let's start out by kind of getting a little bit more into the weeds here.
[10:12.940 --> 10:19.160]  My focus in this area is going to be more on hospitals and the vulnerabilities involved with
[10:19.160 --> 10:25.060]  hospitals. To start off with, here's a little bit about me. I don't really want to spend too much
[10:25.060 --> 10:31.580]  time on this particular page other than to say I've got a lot of experience across a lot of
[10:31.580 --> 10:37.780]  hospitals. It gives me a unique perspective to see some interesting patterns. And unfortunately,
[10:37.780 --> 10:43.600]  I'm here to scare the crap out of you a little bit about how insecure hospitals really are.
[10:43.600 --> 10:47.900]  And then hopefully I'll be able to motivate you guys to do something about that.
[10:48.060 --> 10:52.560]  Let's first talk about the most important thing here, and that's inventory.
[10:53.840 --> 11:00.200]  When I'm dealing with hospitals, particularly the ones that come into my environment where
[11:00.200 --> 11:04.860]  we start supporting them for the first time, they never have an inventory. If we're lucky,
[11:04.860 --> 11:12.100]  they've got a spreadsheet similar to one that St. Ellis here has. If you get a chance,
[11:12.100 --> 11:19.080]  please participate in the CTF. That's actually the inventory list for the CTF that we used just
[11:19.080 --> 11:24.640]  recently. And it's pretty accurate. It covers pretty much the same thing that I see at hospitals.
[11:25.540 --> 11:29.900]  Now, there are some tools that kind of help us figure out inventories.
[11:30.520 --> 11:35.300]  Lansweeper is my favorite, but there's also Case, SCCM, Configuration Manager,
[11:35.300 --> 11:40.500]  and then you can get real manual with Nmap, Mascan. Those will kind of get you about 80%
[11:40.500 --> 11:47.880]  of the inventory, but it's still going to be mostly accurate. And the reasons for some of that is
[11:49.620 --> 11:53.420]  because there are things that are getting added and removed to the environment all the time,
[11:53.420 --> 11:59.020]  and the spreadsheets never get updated. And there's always the fun one where there's
[12:00.340 --> 12:07.620]  a grant that comes along, and the vendor comes in and installs the devices in the environment
[12:07.620 --> 12:15.360]  and doesn't tell IT or IS, and all of a sudden IT and IS have to support these tools, and it's
[12:15.360 --> 12:21.780]  kind of a mess. So starting out from the very basics, inventories is one of those vulnerabilities
[12:21.780 --> 12:25.160]  that we kind of have to deal with and start figuring out how to get a better inventory
[12:25.160 --> 12:30.700]  for hospitals. The next one we're going to move into is actually discovering vulnerabilities.
[12:30.700 --> 12:36.560]  Now, I like to start out with an external scan to figure out all of the stuff that a hospital
[12:36.560 --> 12:42.800]  has put out on the internet that they use to communicate over the internet. Generally speaking,
[12:42.800 --> 12:49.340]  when those first hospitals come into our support area, they are very, very vulnerable,
[12:49.340 --> 12:55.100]  and we have to start narrowing that down. You can see the little spreadsheet to the left there.
[12:55.120 --> 13:00.240]  That's about a year ago, and I'm proud to say that most of those in the critical areas have
[13:00.240 --> 13:06.120]  at least moved off. But when, like I said, when a new hospital comes in, they're very,
[13:06.120 --> 13:10.620]  very vulnerable. Nobody knows what they've got out on the internet. It's always a fun
[13:10.620 --> 13:17.580]  little situation. And there are a lot of tools that can be used to do this. I use Tenable.io
[13:17.580 --> 13:20.740]  and the reference page. You'll get to see a whole bunch of different other ones.
[13:20.740 --> 13:30.100]  But I also like to bring out Shodan.io and Census.io. Shodan.io is a website that you can
[13:30.100 --> 13:35.320]  go to, Shodan.io, and you can search for medical devices on it and see how many are actually
[13:35.320 --> 13:39.780]  published on the internet that you have access to. In the particular case here,
[13:39.780 --> 13:45.060]  I put PAX in there, and there's about 700 plus medical devices published on the internet that
[13:45.060 --> 13:49.820]  you have access to that you can see about. And if you click on the IP of that particular device,
[13:49.820 --> 13:53.780]  you'll be able to see the CVs and all the things that are vulnerable for that device.
[13:53.780 --> 14:01.560]  Kind of a scary little thing. Now, as bad as the external scan is, scannable IPs on the internet,
[14:01.560 --> 14:06.000]  the internals are always much, much worse. Because hospitals usually design systems where
[14:06.000 --> 14:10.600]  they have this nice, hard firewall that is supposed to protect them from all the different
[14:10.600 --> 14:17.000]  types of things. And then once you get inside, it's not much security whatsoever. So it's like
[14:17.000 --> 14:23.220]  that nice little M&M hard candy shell, soft inside. Nice and scary stuff. So how does this
[14:23.220 --> 14:30.700]  kind of come about? Well, I kind of blame it a lot of it on availability. And then we're talking
[14:30.700 --> 14:36.260]  about the CIA availability, confidentiality, integrity, and then availability. Availability
[14:36.260 --> 14:42.820]  is king when it comes to hospitals. If you've ever seen a physician get upset about not being
[14:42.820 --> 14:48.740]  able to access what they need right then and there, it's quite a terrifying experience.
[14:48.740 --> 14:53.060]  They usually take it out on everybody. And rightfully so, because we're talking about life
[14:53.060 --> 15:00.640]  and death here. So that tends to be one of the challenges that we have to deal with for patch
[15:00.640 --> 15:05.080]  Tuesday that comes out, everything getting patched. How do you reboot something when it has to be up
[15:05.080 --> 15:08.320]  for that surgery that's going to take place at six o'clock in the morning
[15:08.320 --> 15:14.840]  the next day? And we could also talk about maybe N plus one and having server farms,
[15:14.840 --> 15:20.280]  but hospitals are kind of cheap. And that leads to my next one where fast and cheap is far, far
[15:20.280 --> 15:27.280]  more important than good or having it built accurate or done with quality. So the fast and
[15:27.280 --> 15:33.020]  cheap is always going to win. Nobody really cares how good it is or the quality of it is.
[15:33.020 --> 15:37.340]  They just want it set up and running and they don't worry about anything else.
[15:38.600 --> 15:42.980]  Now, of course, that leads to all kinds of fun little problems because Microsoft is a
[15:42.980 --> 15:48.360]  wonderful company that gets everything to work fairly well. That's kind of one of their goals.
[15:48.360 --> 15:53.120]  Everything's got to work, but they turn on all the services by default.
[15:53.120 --> 15:56.920]  And when you're pushing something out fast and cheap, you push it out with the default settings.
[15:56.920 --> 16:01.020]  So here we are set up with all these services that we don't need that are running and they're
[16:01.020 --> 16:06.160]  now vulnerable because they haven't been patched in at least six months or so.
[16:07.560 --> 16:14.180]  The next one is kind of a more challenging one and probably the most important one,
[16:14.180 --> 16:20.040]  both IT and IES. Really, we kind of suck at talking to humans. We're great at talking about
[16:20.040 --> 16:26.480]  technology and working with computers and communicating along those routes. And the
[16:26.480 --> 16:32.420]  staff, they don't talk tech at all. They talk human. They're worried about emotions and they're
[16:32.420 --> 16:37.940]  worried about being able to understand people's needs and wants and desires and they don't care
[16:37.940 --> 16:41.680]  about the technology. That's just the thing that's there that kind of gets in their way
[16:41.680 --> 16:47.140]  and hopefully will help them out just a little bit. And then the last one I want to talk about
[16:47.140 --> 16:53.820]  is there's really no accountability. There's also no incentive to do better or to fix all
[16:53.820 --> 17:00.600]  these types of things. So it kind of to Chloe's point earlier there in her talk,
[17:00.600 --> 17:06.580]  she mentions that there's all these different laws out there, but there's no laws about making sure
[17:06.580 --> 17:15.770]  that medical devices or hospital devices are secure and not going to cause us problems.
[17:17.020 --> 17:20.460]  And there's also no incentive. There are a few nice little things, hopefully Casey will
[17:20.460 --> 17:26.600]  cover some of that stuff in his talk. So next I'm going to talk about my solution for this.
[17:26.600 --> 17:33.280]  And the key word is communication. Now we as IT, information security, IS, we've got to do much,
[17:33.280 --> 17:38.740]  much better at communication. We've got to figure out how to communicate with our target audience.
[17:38.800 --> 17:43.280]  We've got to figure out how to deliver our message to our target audience. We've got to be able to
[17:43.280 --> 17:49.700]  read our target audience and get better at understanding when our target audience understands
[17:49.700 --> 17:56.120]  our message. And we may have to modify our message to get that across. Once we're able to effectively
[17:56.120 --> 18:00.420]  communicate, you know, those horrible soft skills that nobody ever wants to work on because it's
[18:00.420 --> 18:05.620]  boring and challenging and difficult. Once those are down, then we can start talking about ensuring
[18:05.620 --> 18:13.020]  that integrity and confidentiality of data is maintained. And it's just as important, if not
[18:13.020 --> 18:19.200]  more important than the availability of the data. And we'll be able to talk about how quality
[18:19.200 --> 18:25.880]  is just as important, maybe more so, and even cheaper in the long run than getting something
[18:25.880 --> 18:31.920]  out as fast as possible, as cheap as possible. And then we can also start convincing those
[18:31.920 --> 18:38.980]  politicians to hold people accountable and people, meaning the CEO boards, all those people that
[18:39.840 --> 18:45.380]  build corporations in order to avoid being accountable to different things. And we'll be
[18:45.380 --> 18:52.680]  able to start building out some incentives to help us have reasons to do things rather than
[18:52.680 --> 19:00.440]  reasons not to do things. Next, I want to talk about something that kind of scares me. Last year
[19:01.010 --> 19:06.320]  at the Biohacking Village, there was a conversation going on, and I believe Beau had said this,
[19:06.320 --> 19:13.880]  and it was about how physicians don't really care about security because there's no body
[19:13.880 --> 19:20.820]  count associated with security. There's no direct correlation of a medical device killing people.
[19:21.200 --> 19:24.320]  And to be honest, I think medical devices are being used to kill people.
[19:25.820 --> 19:31.240]  And there's really no way to tell if they have or they haven't been used to kill people because
[19:31.240 --> 19:38.440]  we don't have the technology in place to detect that. There's no SOCs, there's no SIMs, there's
[19:38.440 --> 19:45.640]  no IPS, there's no logs, there's none of that good stuff. Not at least at hospitals. At hospitals,
[19:45.640 --> 19:52.660]  they have a firewall and they have anti-virus type situations. And at hospitals, technology
[19:52.660 --> 19:59.840]  is very, very far behind everybody else. Pagers are still being used, fax machines in multifunction
[19:59.840 --> 20:07.160]  printers are being used to fax between floors. Just this morning, I had a fun conversation about
[20:07.160 --> 20:13.900]  how a CD was being sent from one hospital to another hospital and how it's important to
[20:13.900 --> 20:20.300]  verify the data on that CD, how it's important to make sure that there's no viruses on that CD,
[20:20.300 --> 20:25.720]  and if they're going to be communicating through CDs, they should probably encrypt the data,
[20:25.720 --> 20:28.520]  all of which I don't think any of that has been done.
[20:30.460 --> 20:35.060]  Now, kind of to bring it back around, I posted a little image here. It's from 2004
[20:35.060 --> 20:39.820]  about the arrest rates and percentage of crimes cleared. And as you can see,
[20:39.820 --> 20:44.740]  murders are solved about 62% of the time. So even if
[20:46.920 --> 20:51.840]  a murder is committed, then there's a pretty good chance, 40% chance that
[20:53.240 --> 20:57.100]  whoever commits the murder is also going to be able to get away with it. And that's
[20:57.100 --> 21:03.160]  just the way it is with all the legal and law enforcement areas. As I mentioned, it was 2004
[21:03.160 --> 21:08.220]  when this particular one came out. If you do a search and check, that hasn't changed. It's still
[21:08.220 --> 21:17.340]  right around 60%. So we need to do better. We need to start using a communication like I talked
[21:17.340 --> 21:23.760]  about to start holding people accountable and just start providing incentives to ensure that
[21:23.760 --> 21:27.740]  these medical devices aren't actually killing people. Got to figure it out.
[21:27.740 --> 21:33.420]  Now here's a little scary thought for everybody. If hospitals have to invest in
[21:35.160 --> 21:39.500]  these monitoring site solutions, then the hospitals are also going to have to invest
[21:39.500 --> 21:46.960]  in ways to prevent that from happening. All of this is a huge cost effort and hospitals
[21:46.960 --> 21:53.140]  don't make very much money. A lot of it is spent on administration and they would much
[21:53.140 --> 21:58.820]  rather buy an MRI machine than they would spend the money on securing something. So I'm going to
[21:58.820 --> 22:04.280]  drive home that we've got to set up some incentives. All right, let's pull up this
[22:04.280 --> 22:08.500]  last slide because I don't want to end on too scary or say out of a note. Everybody's trying
[22:08.500 --> 22:12.840]  their absolute best in everything that they're kind of doing. Hopefully we'll all keep trying
[22:14.640 --> 22:21.440]  and hopefully we'll get better and learn more and just kind of do the best we can.
[22:22.000 --> 22:26.500]  I'll also throw this up. Here's the references. I'm sure that at a certain point the slides will
[22:26.500 --> 22:33.200]  become available and you will be able to click on the links and utilize the information in these.
[22:33.540 --> 22:38.000]  Thanks for hearing me. I believe Casey's up next and we'll hear from him next.
[22:38.320 --> 22:43.980]  All right, greetings DEF CON. Thank you for joining this talk and thanks to Eric and Chloe
[22:43.980 --> 22:50.180]  leading into my section now. Who the heck is this guy? I am the founder, chairman, and CTO of
[22:50.180 --> 22:54.760]  BugCrowd. My name is Casey Ellis. I've been in information security for about 20 years.
[22:55.720 --> 23:00.620]  From a BugCrowd standpoint, and especially as it relates to vulnerability disclosure,
[23:00.620 --> 23:05.880]  BugCrowd actually pioneered the crowdsource security as a service space. So, you know,
[23:05.880 --> 23:09.860]  vulnerable disclosure and bug bounty predates us by a long way, which I'll get to in the talk.
[23:09.860 --> 23:13.780]  We were the first to actually get in the middle and try to make it work better. So, you know,
[23:13.780 --> 23:18.920]  pretty proud of that, but it means we've learned a lot about how that works from a process standpoint.
[23:18.920 --> 23:24.460]  From a journey standpoint, for me, you know, I started life as a hacker. I got into Pentest as
[23:24.600 --> 23:30.220]  a career, moved across into the dark side of security solutions and sales, and then broke
[23:30.220 --> 23:35.780]  bad and became an entrepreneur, which eventually led to starting BugCrowd in 2012. And yeah,
[23:35.780 --> 23:40.540]  you can see the, you know, the hack persona and the hustle persona on the side that pretty much
[23:40.540 --> 23:45.620]  sums up who I am and how I do what I do. So now you know me. That's where to find me as well.
[23:46.540 --> 23:52.180]  So yeah, with respect to the talk, you know, when we started BugCrowd, it was really all about,
[23:52.180 --> 23:56.980]  like, how do we do this? Well, there's this enormous community of white hats from all around
[23:56.980 --> 24:02.720]  the world, which Eric's talked about, and some of the things that they can do. And, you know,
[24:02.720 --> 24:08.620]  this incredible need for security feedback in all sorts of areas of cybersecurity. Like,
[24:08.620 --> 24:14.740]  how do we make this easy to do it well? How can you connect that latent potential with the unmet
[24:14.740 --> 24:21.060]  demands of security itself? And, you know, on this, like, if you look at it simplistically,
[24:21.060 --> 24:25.520]  it's a fairly easy problem to solve. You just invite a conversation to happen and everything's
[24:25.520 --> 24:30.740]  great. But it turns out there's a lot of devil in the detail, which is, you know, we did anticipate
[24:30.740 --> 24:34.500]  that when we started off, but it's a lot of what we've been continuing to work on over the last
[24:34.500 --> 24:39.880]  eight years. And Disclose.io, which is what I'm going to talk about today, is a product actually
[24:39.880 --> 24:47.540]  of the policy and really the adoption of vulnerability disclosure component of that.
[24:47.540 --> 24:54.100]  Like, at this point, we're a ways along from where we were even back in 2012. I think nowadays
[24:54.100 --> 24:59.980]  vuln disclosure is becoming this normalized phenomena, and it's starting to become a lot
[24:59.980 --> 25:05.160]  of social pressure around it, which I think is a really good thing. It's still the company,
[25:05.160 --> 25:11.200]  the kind of thing, rather, that you're a bit special if you do, as opposed to being,
[25:11.200 --> 25:16.140]  you know, abnormal or unusual if you don't do it. And really, Disclose.io is about flipping that,
[25:16.140 --> 25:22.500]  but I'll not preempt myself anymore, and we'll get into a bit of backstory. So, in 95, Netscape
[25:22.500 --> 25:28.960]  launched the Bugs bounty program. They've since dropped the S because it's cleaner, and that is
[25:29.040 --> 25:35.900]  a Silicon Valley joke for anyone who missed it. There's lockpick bounty programs. There's all
[25:35.900 --> 25:40.180]  sorts of other things that go back centuries, even, around getting security feedback through
[25:40.360 --> 25:48.040]  a reward model. But Netscape's broadly accepted as the first kind of high-tech bug bounty program.
[25:48.040 --> 25:54.460]  And really, with that, kind of almost the instantiation of being proactive around
[25:54.460 --> 25:58.940]  vulnerability disclosure and actually inviting and engaging it as a part of your security process.
[25:58.940 --> 26:04.000]  So, bug bounties and vulnerability disclosure, they're not the same thing. Don't let anyone tell you that they are.
[26:04.700 --> 26:09.620]  But they look enough, they look similar enough in terms of how they operate that, you know, we put
[26:09.620 --> 26:14.980]  that back down to kind of where this whole idea started to really gain momentum. You know, Bug
[26:14.980 --> 26:19.920]  Crowd started in 2012, and in 2013, I've got these flipped around, but you get it. One of the
[26:19.920 --> 26:26.460]  things that we noticed was, you know, legal teams don't seem to really understand how to write a
[26:27.300 --> 26:32.200]  policy that is almost the opposite of everything they've written before it. So, you've traditionally
[26:32.200 --> 26:38.360]  gone out saying, hey, if you're a hacker, go away, you're bad, and here's all of the legal stuff to,
[26:38.360 --> 26:43.220]  you know, create a legal framework for us to say that to you. Now, we're starting to try to get our
[26:43.220 --> 26:47.840]  heads around the idea that, you know, there's locksmiths as well as burglars out there, and we
[26:47.840 --> 26:52.620]  actually want the help of the locksmiths. Legal teams don't know how to do that. It's still, I
[26:52.620 --> 26:59.080]  believe, a net new kind of idea in the space of law. And the challenge is with legal teams, you
[26:59.080 --> 27:02.480]  know, when they don't, when they're uncertain about what they're doing, they tend to write
[27:02.480 --> 27:08.300]  war and peace. Like, they'll err on the side of verbosity. So, you end up with these great big,
[27:08.300 --> 27:13.000]  long, confusing briefs, and that's the first part of the problem. The second part is that hackers
[27:13.000 --> 27:18.120]  don't read those things in the first place. They should, but it's the yielder problem. You know,
[27:18.120 --> 27:22.340]  I think you get a subset of the community who actually really do dig in, and we're very grateful
[27:22.340 --> 27:26.220]  for them. But you've got to expect the behavior from the internet that people are just going to
[27:26.220 --> 27:31.680]  click through, look for the thing to do next, and go, which is certainly true also in this space.
[27:31.960 --> 27:36.840]  And the challenge is that when you talk about, you know, the anti-hacking laws and some of the
[27:36.840 --> 27:41.960]  provisions that have been invoked to chill security research that Chloe was talking about earlier,
[27:41.960 --> 27:47.360]  you know, the CFIA makes screwing this up as a hacker potentially a felony crime. And the same
[27:47.360 --> 27:52.960]  is true for similar laws in other countries. So in 2014, we thought, all right, let's try to
[27:53.580 --> 27:59.680]  untangle this one and solve it. So we released the Open Source Vulnerability Disclosure Framework
[27:59.680 --> 28:06.720]  in partnership with Jim Dinaro and the folk over at Cypher Law out of DC. And that was awesome.
[28:06.720 --> 28:11.380]  It was basically this idea of, like, how do we, you know, kind of compress down the really
[28:11.380 --> 28:15.600]  important things that need to be in a brief like this to the point where people can theoretically
[28:15.600 --> 28:22.760]  just copy paste and get it right like 90% of the time. At the same time, Katie, Art, a bunch of
[28:22.760 --> 28:27.120]  others in InDisclosure were working on the ISO standards. They got released to paying customers.
[28:27.120 --> 28:32.360]  So there was this kind of convergence on trying to solve this problem of standardization. Fast
[28:32.360 --> 28:39.280]  forward to 2018, what we did was basically take some of the, well, actually kind of capitalized
[28:39.280 --> 28:45.400]  on some of the attention that was around this concept of legal safe harbor. Thank you to Amit
[28:45.960 --> 28:51.980]  for really pushing that forward and her legal bug bounty initiative. And then Dropbox and a couple
[28:51.980 --> 28:57.840]  of other folks that were going on took the OSVDF and legal bug bounty, merged them, and put them
[28:57.840 --> 29:03.320]  all under Disclose.io. Bug crowd added it as default and off we went from there. So that's
[29:03.320 --> 29:07.840]  the backstory. And I think with respect to CFAA, you know, it's important to keep in mind that it
[29:07.840 --> 29:14.680]  is in active use. I personally believe that there should be laws in place that address
[29:15.220 --> 29:20.880]  computers as a vector to commit a crime. But, you know, as Chloe called out, if it's not clear
[29:21.920 --> 29:25.900]  what side of the law you're on, especially when you're trying to help, then there's a chilling
[29:25.900 --> 29:30.620]  effect that means that security feedback doesn't pass from A to B. And that's always bad. So we're
[29:30.620 --> 29:35.560]  trying to solve that problem. So really what Disclose.io is about is like, how do we make
[29:35.560 --> 29:41.380]  this idea of vuln disclosure, how do we make the adoption of a vulnerability disclosure program go
[29:41.380 --> 29:47.200]  viral? And doing it with best practice. How do we make that into something that is not this huge
[29:47.200 --> 29:53.460]  push from companies like Bug Crowd and people in the researcher community? Not this like reactive,
[29:53.460 --> 29:58.820]  oh crap, I got tweeted at, what do I do now experience for folk on the vendor side? Something
[29:58.820 --> 30:04.640]  that, you know, the internet collectively is leaning into and doing well. And that really is
[30:04.640 --> 30:10.860]  the mission of Disclose.io. It's a healthy and ubiquitous internet immune system and props to
[30:10.860 --> 30:17.380]  Karen Elazari, Amit's sister, for I think making that concept of hackers operating as the immune
[30:17.380 --> 30:23.620]  system of the internet popular in her TED talk. Feels like a billion years ago at this point, but
[30:23.620 --> 30:29.780]  it was a little while back. You know, I think that's true. I think, you know, the healthcare
[30:29.780 --> 30:36.320]  sector and the internet in general's rejection of security input or its inability to identify
[30:37.040 --> 30:42.720]  that input as important and good, but then its rejection of that input is kind of like an auto
[30:42.720 --> 30:46.920]  immune deficiency in a lot of ways. And, you know, this is what we're trying to solve. Like,
[30:46.920 --> 30:50.600]  how do we get it to the point where hackers are functioning as the, like the T-cells of the
[30:50.600 --> 30:56.600]  internet and the internet as an organism, as a body is able to cooperate with that and actually
[30:56.600 --> 31:01.300]  have, you know, everything grow up and be big and strong as a byproduct.
[31:02.380 --> 31:07.320]  The mission of Disclose.io is to drive vulnerability disclosure adoption,
[31:07.320 --> 31:12.380]  as I probably made clear at this point, but doing that through safety, simplicity,
[31:12.380 --> 31:16.700]  and standardization. So if that's what you remember about this project, that's going to be
[31:16.700 --> 31:22.920]  kind of the key takeaway because it does involve everyone. It is open source. You know, I'm
[31:22.920 --> 31:27.580]  known for bug crowds, sitting in front of a big bug crowd logo, and this is kind of the commercial
[31:27.580 --> 31:32.480]  concept construct for starting this project. But at this point, we have basically spun it out
[31:32.480 --> 31:37.400]  into its own thing. It's very much something that we want everyone to participate in,
[31:37.400 --> 31:41.700]  regardless of whether they're a customer of my company or not. So that's kind of the goal here.
[31:42.460 --> 31:50.160]  So what is it? How are we doing it? How do you unscrew a 30-year-old problem on the internet?
[31:50.180 --> 31:55.420]  Glad you asked. So there's three main components to it. There's the terms,
[31:55.420 --> 31:59.980]  the purpose of the terms is to make it easy. How do we eliminate the friction of understanding
[31:59.980 --> 32:07.060]  and adopting B2B language in a way that benefits hackers and companies? And the overall outcome of
[32:07.060 --> 32:12.460]  that is ideally standardization of what those terms should look like. Eventually, ideally,
[32:12.460 --> 32:19.860]  to the point where things like CFAA, DMCA, and others start to come under the right kind of
[32:19.860 --> 32:24.800]  pressure to be reformed, to actually accommodate for good faith in our space. I think that's the
[32:24.800 --> 32:29.260]  utopian goal. We're a ways off from that. And there's a lot of other things for the legal folk
[32:29.260 --> 32:34.500]  to be occupying themselves with right now. But in the meantime, we can do our part.
[32:34.640 --> 32:41.340]  The second piece is the list, which is to aggregate adoption and really to drive adoption as well.
[32:41.660 --> 32:45.420]  The whole idea there is network effect, which is that kind of virality piece I was talking about
[32:45.420 --> 32:52.240]  before. How do we get it all into the one spot in a way that basically creates this critical mass of
[32:52.240 --> 32:57.640]  best practice that people are actually drawn to? And the third piece is the logo, which is
[32:57.640 --> 33:02.640]  really normalization. I'll go into these in a second because I'm kind of getting ahead of it.
[33:02.640 --> 33:11.340]  But how do we promote best practice? I think VDP is a little bit unique in terms of security things
[33:11.340 --> 33:16.820]  that a company can do because a non-technical user can understand it. They might not get
[33:16.820 --> 33:23.780]  blockchain-enabled, AI-powered, next-gen endpoint something, something. But the idea of neighborhood
[33:23.780 --> 33:27.620]  watch for the internet, especially when you're talking about a safety-critical space like
[33:27.620 --> 33:34.140]  medical, anyone can get that. And we're at a point in time where I think the average human is more
[33:34.140 --> 33:39.120]  concerned about the risk that they have when they're buying a product than ever before. So this
[33:39.120 --> 33:43.720]  becomes something that's actually a benefit aside from the security benefit and the fact that
[33:43.720 --> 33:48.280]  it's just the right thing to do. The goal with this is for it to almost become like the green
[33:48.280 --> 33:55.460]  padlock for SSL. And I say that fully mindful that people started to remove the green padlock
[33:55.460 --> 34:01.640]  because it has been normalized. If this whole idea of VDP adoption can go through that same arc,
[34:01.640 --> 34:06.340]  I would be incredibly happy. And I think pretty much everyone in this space would benefit from
[34:06.340 --> 34:12.620]  it as well as the internet itself. So, all right, the terms. It is a collection of boilerplate,
[34:12.620 --> 34:18.980]  full disclosure templates. Some folks just copy-paste it. With the OSVDF, the initial
[34:18.980 --> 34:23.680]  incarnation of this, we noticed the language popping up everywhere. It was getting translated
[34:23.680 --> 34:30.440]  into different languages. That document has grandfathered into policies all over the internet
[34:30.440 --> 34:35.160]  at this point. And that's just the thing that people do. So, okay, you can do that. Or you can
[34:35.160 --> 34:39.700]  use it as a foundational framework or a starting point for new versions, which is one of the reasons
[34:39.700 --> 34:44.760]  that it's open source. We've actually taken input from programs who've looked at the policy,
[34:44.760 --> 34:49.040]  said, hang on, here's an edge that a lot of people have that you probably haven't considered
[34:49.040 --> 34:53.520]  that we're going to write in. You should consider it, issued a pull request, and we've actually
[34:53.520 --> 34:58.620]  merged that into the language over time. It's open source, as I keep saying, because I want
[34:58.620 --> 35:04.420]  to really stress that point. It's licensed under CCA 4.0, so anyone can use it. And some of the
[35:04.940 --> 35:10.260]  represented in the NASCAR section here are the kind of people that are helping out.
[35:10.740 --> 35:14.620]  This isn't an endorsement from them of the project itself, but it's the kind of folks that are
[35:14.620 --> 35:20.020]  participating on an individual level to making that language better and driving this forward.
[35:20.020 --> 35:24.020]  These are the kind of folks that are actually rocking up and assisting. So that's the other
[35:24.020 --> 35:29.040]  benefit of open source. It's not just, you know, Casey the Bush lawyer from Australia's opinion
[35:29.040 --> 35:33.360]  on how to do this as well. It's all sorts of different folks that are actually coming in and
[35:33.360 --> 35:39.780]  making the whole thing more and more effective over time. And honestly, like, this is the
[35:39.780 --> 35:44.840]  interesting part, I find, is that it's actually kind of hard to do. You know, one of the things
[35:46.800 --> 35:50.680]  that's a challenge, frankly, that needs to be overcome, because it's a function of how it works,
[35:50.680 --> 35:57.200]  is that not every hacker is a lawyer. In fact, most aren't, I would say. And many of them,
[35:57.200 --> 36:01.560]  I would say most, are English as a second language. So you've got to be able to actually
[36:01.560 --> 36:05.660]  articulate what the hell you're trying to do in this brief in a way that if they do read it,
[36:05.660 --> 36:10.060]  they can understand what's okay and what's not. So you've got to balance this readability and brevity
[36:10.600 --> 36:15.660]  with legal completeness. Obviously, you want to provide safety to whatever degree you can
[36:16.340 --> 36:23.480]  without going overboard and having it turn into this 12-page read-fest. And the safety that's
[36:23.480 --> 36:28.200]  provided by the clauses in this type of thing need to be bilateral. They need to protect the
[36:28.200 --> 36:32.840]  company that's putting it up on their policy. And it needs to, more importantly, I think in
[36:32.840 --> 36:38.160]  context of this talk, protect that hacker as they're doing research. Or even, you know, the
[36:38.160 --> 36:42.940]  concerned citizen who's found a bug, not as a product of security research, that just wants
[36:42.940 --> 36:47.300]  to send it across and doesn't know if that'll get them sent to jail or not. So at the moment,
[36:47.300 --> 36:52.860]  it's covering US, Canada, the Netherlands, and Belgium. And we wrote one for the 2020 US
[36:52.860 --> 36:59.920]  presidential elections. That was tough because there's obviously a lot to consider there. That's
[36:59.920 --> 37:04.560]  the sort of problem sets that we're trying to tackle with these terms and with the goal of
[37:04.560 --> 37:11.220]  making it easy and standardized. The list itself is this true community-powered vendor-agnostic
[37:11.220 --> 37:16.860]  directory of all known BDPs and bug-banning programs. At the moment, we've got, you know,
[37:16.860 --> 37:21.240]  what kind of legal protections afforded by the program, what kind of rewards does it offer.
[37:21.240 --> 37:27.940]  We're about to integrate support with security.txt. And I think calling it at the disclosure models
[37:27.940 --> 37:32.800]  and timelines, if it's a coordinated vulnerability disclosure model, that's going to be different for
[37:32.800 --> 37:38.800]  every organization. So we've accommodated that in there as well. Again, open source licensed under
[37:38.800 --> 37:44.020]  CCA. So that brings us to the seal. This is like the green padlock part that I was talking about
[37:44.020 --> 37:48.080]  at the front. What we've done at this stage, this will continue to evolve, but where it's up to at
[37:48.080 --> 37:54.340]  this point is dividing out what we're referring to as safe harbor, or as popularly, I think at
[37:54.340 --> 37:59.400]  this point, referred to as safe harbor. What that's really talking about is what kind of legal protections
[37:59.400 --> 38:05.120]  are available to the researcher that have been proactively included by the program owner into
[38:05.120 --> 38:11.080]  the program. And we've broken it into partial safe harbor and partial, like a partial compliance
[38:11.080 --> 38:15.980]  statement and a full safe harbor or a full compliance statement. The difference between
[38:15.980 --> 38:21.540]  those two things, I think is quite important. For partial, what we're referring to as partial
[38:21.540 --> 38:26.120]  safe harbor, essentially, it's a good faith statement. So it's this idea that, hey, we agree
[38:26.120 --> 38:32.580]  not to lower up and cause you a hard time if you play by these rules, which is better than
[38:32.580 --> 38:38.120]  there being nothing there, right? Because that's when, you know, there's, I think the risk can be
[38:38.120 --> 38:42.540]  quite high. And there's even recently examples of where that sort of thing's gone wrong.
[38:43.180 --> 38:47.800]  That statement in of itself is a good start. The problem is that you're still potentially
[38:48.460 --> 38:54.160]  technically committing a crime as you conduct security research. And that's the part where
[38:54.160 --> 38:59.160]  there's still, I think, a decent amount of exposure. I liken it to, you know, in California,
[38:59.960 --> 39:04.880]  on the highways, the speed limits 60 miles an hour, but everyone drives at 80 and you don't
[39:04.880 --> 39:10.240]  get pulled over, right? And that's because there's this sort of social contract. It's not quite,
[39:10.240 --> 39:14.880]  that would be no safe harbor because it's not written down anywhere, but kind of everyone knows.
[39:15.660 --> 39:20.460]  It's sort of the same thing. You could get pulled over for that, but you just don't.
[39:20.460 --> 39:25.440]  Full safe harbor would be the analog to actually increasing the speed limit to what people will
[39:25.440 --> 39:32.860]  drive at and putting it on the speed sign. So at that point, there's no recourse for you to be,
[39:32.860 --> 39:36.720]  you know, issued a speeding ticket in that context. I'm doubling down on this driving
[39:36.720 --> 39:42.460]  metaphor, but I think it's a neat way to explain it. And to basically get full compliance in
[39:42.460 --> 39:49.080]  context of Disclose.io, there needs to be provision against anti-hacking laws. So authorization is
[39:49.080 --> 39:53.860]  typically the hinge term. It certainly is with CFAA and the same is broadly true around the world.
[39:54.620 --> 39:59.780]  Exemption against any circumvention laws like DMCA, which is very relevant to medical device
[39:59.780 --> 40:06.180]  research. Exemption against acceptable use or TOS violation because you're breaking the thing and
[40:06.180 --> 40:10.680]  that shouldn't mean that you're breaking the law if you're doing security research. And a general
[40:10.680 --> 40:15.720]  acknowledgement of good faith as well. And this is the part where, you know, we'll get to how this
[40:15.720 --> 40:20.980]  all works because ideally, and we've started to see this happen, but this is where everyone can help.
[40:21.760 --> 40:27.180]  An organization initiates a Vulnerable Disclosure Program. It gets added to the list. People see
[40:27.180 --> 40:33.480]  that and look at it, then say, oh, well, where are you at with these safe harbor clauses? Where are
[40:33.480 --> 40:38.740]  you at with the legal protections that you're giving researchers to actually try to help you
[40:38.740 --> 40:44.000]  out here? The organization's like, oh, I didn't even really think of that because oftentimes that's
[40:44.000 --> 40:48.900]  true. They go back, look through the boilerplate stuff, you know, work out what they're going to
[40:48.900 --> 40:52.740]  include or how they're going to adapt their policies. It gets updated in the list. And at
[40:52.740 --> 40:59.360]  that point, they're issued with the logo. Should an organization actually take that logo and use it
[40:59.360 --> 41:03.800]  to promote the fact that they've got a VDP or promote the fact that this is part of their
[41:03.800 --> 41:08.780]  cybersecurity process? At that point, hackers see it and they start to help out, which is good.
[41:09.200 --> 41:14.600]  Customers see it and they trust them more, which is good. The part I like best is that their peers
[41:14.600 --> 41:20.360]  from a vertical standpoint see it and ask themselves, why am I doing that? I should
[41:20.360 --> 41:26.540]  probably do that too. Like if, you know, we're in a vertical with five players in it, four are doing
[41:26.540 --> 41:32.000]  it, one's left out, that one looks like a schmuck and no one wants to be that company. So it's
[41:32.000 --> 41:37.960]  basically increasing lateral social pressure to adopt vulnerability disclosure and actually do
[41:37.960 --> 41:45.060]  this well. And, you know, it feels too soon to be talking about... I was actually talking about this
[41:45.060 --> 41:53.800]  in context of virality and network effect before COVID broke out. But, you know, without disrespecting,
[41:53.800 --> 41:57.220]  I think the pain that that's causing a lot of people right now, I think it actually illustrates
[41:57.220 --> 42:03.780]  the idea pretty effectively. Like how do we take this concept of doing the right thing,
[42:03.780 --> 42:08.860]  making people more secure, doing the right thing by hackers, and just generally improving the
[42:08.860 --> 42:13.680]  security of the internet and actually make that viral? That's really the goal that we've got here.
[42:14.360 --> 42:19.920]  So how does it relate to medical security? What can we achieve in 2020? The first, and this is a
[42:19.920 --> 42:25.700]  call for help, is to adapt the terms to the medical device sector in particular. I think
[42:25.700 --> 42:34.060]  the medical sector in general would be great too. You know, I think the election security
[42:34.760 --> 42:38.740]  revision that we did, it took a lot of work and a lot of thoughtfulness from people that are
[42:38.740 --> 42:43.360]  involved in that space because there's a lot of edge cases that are specific that needed to be
[42:43.360 --> 42:47.820]  considered and factored in and then you needed to simplify that. So you can't just add crap on
[42:47.820 --> 42:53.880]  because that violates the simplicity design goal of the terms. So lawyers that are up for that,
[42:53.880 --> 42:58.880]  please do reach out. As people adopt full disclosure in medical security, we want to
[42:58.880 --> 43:03.660]  see at least 30% of them with this full authorization statement. Ideally higher,
[43:03.660 --> 43:08.860]  like I'd love to see it get to 100% at some point in the future, but 30% seems like a great place to
[43:08.860 --> 43:13.800]  start. Across the thousand-odd programs that we're tracking at the moment, compliance is about
[43:13.800 --> 43:20.220]  at about 13%. I think last time I checked. So, you know, there's a gap there, but it's a
[43:20.220 --> 43:27.000]  bridgeable gap. So I think that's a good goal. And I think specific to COVID, you know, this is
[43:27.000 --> 43:31.800]  something that we've been pushing on commercially as bug crowd, but also just in general at a policy
[43:32.340 --> 43:39.840]  level. You know, how can we use this to basically unscrew the problem of COVID contact tracing,
[43:39.840 --> 43:43.980]  both from a security and privacy standpoint, but then also from an adoption standpoint?
[43:44.080 --> 43:48.620]  You know, one of the things that's preventing people from adopting rightly or wrongly,
[43:48.620 --> 43:53.760]  or perhaps rightly and wrongly from adopting contact tracing applications is they don't
[43:53.760 --> 43:58.100]  trust the security implication. They don't trust the privacy implication. They don't trust the
[43:58.100 --> 44:04.200]  government, the folks that wrote it, like whatever the individual excuse or reason might be.
[44:05.240 --> 44:12.160]  It's sort of similar to, you know, the conversation before around like, this is
[44:12.160 --> 44:17.200]  Neighborhood Watch for the internet. If there's transparency, if there's like this known kind
[44:17.200 --> 44:21.660]  of group of people that are constantly working to help improve this stuff for their own safety
[44:21.660 --> 44:26.480]  as hackers and as members of this community, all of a sudden, you know, we solve all of those
[44:26.480 --> 44:31.940]  problems with really the one shot, you know, obviously providing the issues are getting fixed,
[44:31.940 --> 44:36.640]  which we're not addressing in this. We are just talking about vulnerability intake and policy.
[44:36.640 --> 44:42.760]  That whole vulnerability management pieces is very much a separate but adjacent subject. I
[44:42.760 --> 44:46.740]  don't want to confuse the two there, but you can sort of see the model here. If all of a sudden
[44:47.100 --> 44:51.760]  a government or an agency is turning around saying, cool, this is our solution. These are
[44:51.760 --> 44:55.440]  the concerns that we know you have. This is how we're addressing them. And by the way, the
[44:56.060 --> 45:04.020]  should make you more confident. If that drives up adoption rates of safe and privacy conscious
[45:04.020 --> 45:08.840]  contact tracing applications, I think that's part of what makes that particular model of pandemic
[45:08.840 --> 45:13.360]  management work, which is something we need to be thinking about right now. I personally hate
[45:13.360 --> 45:19.840]  that type of solution in any time other than this. I got asked a lot of questions about it and said,
[45:19.840 --> 45:24.980]  yeah, in any other time I'd run screaming from something like contact tracing, I'd recommend
[45:24.980 --> 45:30.280]  that absolutely everyone else do the same thing. But we haven't really dealt with the kind of
[45:30.280 --> 45:34.460]  things that we're dealing with before with technology available as a potential solution.
[45:34.460 --> 45:41.660]  So I think this is a really practical application of it. So help wanted. Lawyers, help us translate
[45:41.660 --> 45:47.160]  the terms. If you want to translate it into a language that you speak in and a jurisdiction
[45:47.160 --> 45:51.560]  where you can be considerate of the particular anti-hacking and anti-circumvention laws that
[45:51.560 --> 45:56.180]  apply, that would be fantastic. We'd appreciate that. We want to see as much of that happen as
[45:56.180 --> 46:01.520]  possible. For hackers, contribute to the list. If there's something missing or if there's a detail
[46:01.520 --> 46:06.040]  that's incorrect, submit a pull request and actually use that list. The idea of it is to
[46:06.040 --> 46:11.940]  help you guys and girls and everyone else who's involved in hacking to be able to look at the
[46:11.940 --> 46:16.860]  target space that's out there that's actually wanting your help and giving you an opportunity
[46:16.860 --> 46:21.540]  to do that. If you want to work on paid programs, go for it. If you want to work on BDPs and
[46:21.540 --> 46:26.200]  verticals that you're passionate about, do it. The goal of the list is to get all of that
[46:26.200 --> 46:31.500]  information in the one spot and make it easy and shareable to everyone and contributions
[46:32.150 --> 46:40.100]  power that. For organizations that might be watching, start talking to your security team,
[46:40.100 --> 46:44.640]  start talking to organizations like Bugcrowd, start talking to hackers about what you need
[46:44.640 --> 46:49.880]  to do to take steps towards being proactive about launching a vulnerability disclosure program and
[46:49.880 --> 46:55.180]  actually engaging the feedback of the hacker community. I think a thing to call out here is
[46:55.180 --> 46:59.920]  you're probably going to get it anyway. And I think that's sort of where this is all going.
[47:00.440 --> 47:05.780]  This idea of the internet being a feedback loop is very quickly becoming normalized.
[47:06.580 --> 47:10.840]  So you can either be reactive to this trend or you can be proactive. And I think being
[47:10.840 --> 47:16.940]  proactive is a better bet. And then include Safe Harbor. And for everyone in the mix, spread the
[47:16.940 --> 47:22.400]  word. Again, this is the reason that we open sourced it. This is the reason that we created
[47:22.400 --> 47:28.740]  this particular brand and this particular logo around the idea. We didn't want this to be purely
[47:28.740 --> 47:32.960]  tied to a commercial initiative. We think this is something that should happen anyway. And I'm
[47:32.960 --> 47:38.820]  speaking as Bugcrowd right now. This is the kind of thing where I think the more input we get,
[47:38.820 --> 47:43.060]  the more it gets spread around, the more people get involved, and the more people adopt it, the
[47:43.060 --> 47:46.920]  better off we all become. And I think that's something that we can all be a part of.
[47:46.940 --> 47:54.060]  That is my spiel on Disclosure. I really appreciate everyone for attending this talk.
[47:54.060 --> 48:00.460]  Thank you to Chloe and to Eric for their sections in the talk. And tying it all together, I think
[48:00.460 --> 48:06.260]  this whole ecosystem of the relationship between the hacker community and hacker feedback loops
[48:06.260 --> 48:12.980]  and the current and future state of security overall and safety as a byproduct of that in
[48:12.980 --> 48:17.540]  the medical sector. Hopefully, we've given you all something to think about today.
[48:18.120 --> 48:19.560]  And now we're going to do some Q&A.
